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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 
60 countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 



Introduction 



In order to meet the need for a digital transmission system suitable for use in all of the bands below 30 MHz, the Digital 
Radio Mondiale (DRM) consortium war formed in early 1998. The DRM consortium is a non-profit making body that 
seeks to develop and promote the use of the DRM system worldwide. Its members include broadcasters, network 
providers, receiver and transmitter manufacturers and research institutes. More information is available from their 
website ( http://www.drm.org/) . 

A large number of communication protocols have been developed to allow reliable exchange of data using a wide 
variety of different techniques. Some have relied on two-way communication to allow requests for re-tries of missing or 
corrupted messages, while others have relied on Forward Error Correcting (EEC) codes such as Reed Solomon to 
rebuild the original message. Unfortunately most of the protocols are tightly coupled to the application they were 
originally developed for, do not scale well in multicast networks or are unsuitable for use over the uni -directional 
circuits often found in distribution systems. When the development of a distribution protocol for Digital Radio 
Mondiale broadcasts was considered, none of the available protocols was deemed suitable and so it was decided to 
develop a general purpose, low-level, reliable communications protocol suitable for both uni-directional and 
bi-directional data links which would meet the needs of DRM but would also hopefully be flexible enough to meet the 
needs of other applications as well. 

The Distribution and Communication Protocol (DCP) describes a common way to transport information over a variety 
of basic transport protocols like IP, serial line or file. It provides transport information, addressing information, 
fragmentation to handle limited basic transport protocols and forward error correction to deal with packet losses or 
packet corruption. The DCP protocol is application-independent and free to use for every organization and purpose. It is 
specified in TS 102 281 [2]. The actual content to be transported in DRM-specific protocols based on DCP (tailored to 
individual purposes) is defined in additional documents like the present one. 
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1 Scope 



The present document defines the actual content to be transported in the DRM-specific protocol Receiver Status and 
Control Interface (RSCI) based on the generic and application-independent Distribution and Communications 

Protocol (DCP) [2]. The RSCI protocol covers the transport of receiver's status information (output protocol) in 
addition to the DRM multiplex as well as commands (control protocol) to control the receiver's behaviour. The 
available TAG items for the RSCI TAG layer within the DCP protocol are defined in the present document. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
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Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 
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[2] ETSI TS 102 821: "Digital Radio Mondiale (DRM); Distribution and Communications Protocol 

(DCP)". Section numbers, where quoted, refer to TS 102 821 (VI. 1.1), 2003-12. 
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Section numbers, where quoted, refer to TS 102 820 (VI. 1.1), 2003-12. 
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numbers, where quoted, refer to TS 101 968 (VI. 1.1), 2003-04. 
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[6] ETSI TR 101 290: "Digital Video Broadcasting (DVB); Measurement guidelines for DVB 

systems". 

[7] ITU-R Recommendation P. 1407: "Multipath propagation and parameterization of its 

characteristics". 



3 Definitions, symbols, abbreviations and convention 

3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply: 

Application Framing (AF): layer of the DCP providing a logical grouping of a number of TAG Items 

Alternative Frequency Switching (AFS): feature of the DRM multiplex, which allows receivers to automatically 
re-tune to a frequency offering more reliable reception without a break in the decoded audio 

byte: collection of 8 bits 
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cell: sine wave portion of duration T^, transmitted with a given amplitude and phase and corresponding to a carrier 
position 

NOTE: Each OFDM symbol is the sum of K such sine wave portions equally spaced in frequency. 

Coordinated Universal Time (literally Universel Temps Coordonne) (UTC): time format counting in standard 

SI seconds with periodic adjustments made by the addition (or removal) of leap seconds to keep the difference between 

UTC and Astronomical Time less that ±0,9 seconds 

NOTE: TAJ and UTC were defined as having an initial offset of 10 seconds on January P' 1972 (TAJ prior to this 
date had a variable fractional offset to UTC as the two times did not use the same definition of the 
second). As at February 25'*^ 2003 there have been 22 leap seconds, all positive, making TAJ = UTC + 32. 

Distribution and Communication Protocol (DCP): transport layer communications protocol providing fragmentation, 
addressing and/or reliable data transmission over error inserting channels using a Reed Solomon (RS) code to provide 
Forward Error Correction (EEC) as defined in TS 102 821 [2] 

Fast Access Channel (FAC): channel of the multiplex data stream, which contains the information that is necessary to 
find services and begin to decode the multiplex 

Global Position System (GPS): constellation of satellites providing accurate time and position information to receivers 

GPS time: time signal broadcast by the GPS satellites using an epoch of January 6* 1980 with no leap seconds and a 
"week number" (actually a modulo-604800 seconds number) that wraps every 1024 weeks (approximately 19,7 years) 

Greenwich Mean Time (GMT): historically the standard time for all international applications, now superseded by 
UTC 

International Atomic Time (literally Temps Atomique International) (TAI): time format counting in standard 
SI seconds 

NOTE: TAJ and GPS Time have a constant offset of 19 seconds. 

logical frame: contains MSC data of one stream during 400 ms 

Main Service Channel (MSC): channel of the multiplex data stream which occupies the major part of the transmission 
frame and which carries all the digital audio services, together with possible supporting and additional data services 

MDI packet: TAG packet containing those TAG items as defined in TS 102 820 [3] 

mod: the modulo operator 

NOTE: (x mod y) = z, where y > 0, such that x = qy + z, q is an integer, and < z < y. 

Modified Julian Date (MJD): date format based on the number of days since midnight GMT on 17''^ November 
1858 AD 

NOTE: Time can be represented as a fraction of a day, however as MJD is subject to leap seconds, the fractional 
part corresponding to an SI second is of variable size and hence complex to implement in a fixed width 
bit-field. 

Multiplex Distribution Interface (MDI): protocol specification for the link between a DRM multiplexer and a DRM 
modulator carrying the description of a complete DRM multiplex in a way that reliable networks of transmitters can be 
constructed as defined in TS 102 820 [3] 

multiplex frame: logical frames from all streams form a multiplex frame (duration of 400 ms) 

NOTE: It is the relevant basis for coding and interleaving. 

OFDM symbol: transmitted signal for that portion of time when the modulating amplitude and phase state is held 
constant on each of the equally-spaced carriers in the signal 

Quality of Service in AM (QoSAM): european project to develop and validate real time tools for measurement and 
monitoring of service quality to insure the best achievable quality according to the propagation channel 

NOTE: More information is available from their website ( http://www.ist-qosam.com) . 
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Recommended Standard 232: interface between data terminal equipment and data communications equipment 
employing serial binary data interchange 

reserved for future addition (rfa): bits with this designation shall be set to zero 

NOTE: Receivers shall ignore these bits. 

reserved for future use (rfu): bits with this designation shall be set to zero 

NOTE: Receivers shall check that these bits are zero in order to determine the valid status of the other fields in 
the same scope. 

Service Description Channel (SDC): channel of the multiplex data stream, which gives information to decode the 
services included in the multiplex 

NOTE: The SDC also provides additional information to enable a receiver to find alternative sources of the same 
data. 

short Id: short identifier assigned to a service and used as a reference in the SDC 

NOTE: The short Id is assigned for the duration of the service and is maintained through multiplex 
reconfigurations. 

SI second: SI base unit of time is the duration of 9 192 631 770 periods of the radiation corresponding to the transition 
between the two hyperfine levels of the ground state of the cesium 133 atom 

stream Id: identifier of an MSC stream 

NOTE: The short Id is the identifier of a service, which is linked by SDC application information data entity - 
type 5 (see ES 201 980 [1], clause 6.4.3.6) or SDC audio information data entity - type 9 (see 
ES 201 980 [1], clause 6.4.3.10) to an MSC stream identified by a stream Id. 

TAG item: DCP elemental type combining in a single logical data the name, length and value of the data 

TAG header: TAG item consists of header and value; the TAG header holds name and length of the TAG item 

TAG length: length of the payload of a TAG item in bits 

TAG name: name field within an individual TAG item used to identify an individual piece of information 

TAG packet: collection of TAG items with a header carrying a cohesive and self-contained block of data 

TAG value: payload of a TAG item 

transmission frame: number of consecutive OFDM symbols (duration of 400 ms), whereby the first OFDM symbol 
contains the time reference/frame synchronization cells 

transmission super frame: three consecutive transmission frames (duration of 1 200 ms), whereby the first 
transmission frame contains the SDC block 

World Geodetic System 1984 (WGS84): is the geodetic reference system used by GPS. The origin of the WGS84 
framework is the earth's centre of mass 

NOTE: GPS receivers compute and store coordinates in terms of WGS84, then if required transform to other 
datums when information is displayed. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

K number of active carriers in the OFDM symbol 

K^.^^ carrier index of the upper active carrier in the OFDM signal 

TTjjjjjj carrier index of the lower active carrier in the OFDM signal 

N^ The value A^ is expressed in radix x. The radix of x shall be decimal, thus 2Ajg is the hexadecimal 

representation of the decimal number 42. 
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duration of a transmission frame, equal to 400 ms 
duration of an OFDM symbol 

the smallest integral value numerically greater than x 

(sometimes known as the "ceiling" function or round towards plus infinity) 

the largest integral value numerically less than x 

(sometimes known as the "floor" function or round towards minus infinity) 



3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AAC Advanced Audio Coding 

AF Application Framing (a DCP protocol layer) 

AFS Alternative Frequency Switching 

AM Amplitude Modulation 

ASCII American Standard Code for Information Interchange 

BER Bit Error Rate 

CELP Code Excited Linear Prediction 

CRC Cyclic Redundancy Check 

DCP Distribution and Communication Protocol 

DMDI DRM Multiplex Distribution Interface 

DRM Digital Radio Mondiale 

ESC Error Sensitivity Category 

FAC Fast Access Channel (a DRM multiplex component) 

EEC Forward Error Correction 

FF File Framing (a DCP Protocol Layer) 

EFT Fast Fourier Transformation 

GMT Greenwich Mean Time 

GPS Global Positioning System 

GUI Graphical User Interface 

HE High Frequency 

HVXC Harmonic Vector eXcitation Coding 

IF Intermediate Frequency 

IP Internet Protocol 

IQ Inphase and Quadrature component 

LSb Least Significant bit 

LSB Least Significant Byte 

MDI Multiplex Distribution Interface 

MER Modulation Error Ratio 

MJD Modified Julian Date 

MSb Most Significant bit 

MSB Most Significant Byte 

MSC Main Service Channel (a DRM multiplex component) 

OFDM Orthogonal Frequency Division Multiplex 

PET Protection, Fragmentation and Transport (a DCP protocol layer) 

PRBS Pseudo Random Bit Sequence 

PSD Power Spectral Density 

QAM Quadrature Amplitude Modulation 

QoSAM Quality of Service in AM 

RE Radio Frequency 

rfa reserved for future addition 

rfu reserved for future use 

RMS Root Mean Square (= square root of the mean squared value) 

RS Reed Solomon 

RS232 Recommended Standard 232 

RSCI Receiver Status and Control Interface 

RX_CTRL Receiver ConTRoL information 

RX_STAT Receiver STATus information 

SBR Spectral Band Replication 

SDC Service Description Channel (a DRM multiplex component) 
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SI International System of units 

TAI International Atomic Time (literally Temps Atomique International) 

TCP Transmission Control Protocol (IP based protocol) 

UDP User Datagram Protocol (IP based protocol) 

UTC Coordinated Universal Time (literally Universel Temps Coordonne) 

WGS84 World Geodetic System 1984 

WMER Weighted Modulation Error Ratio 

3.4 Convention 

AU numbers are decimal, thus the radix is 10, unless otherwise stated by A^^ (see clause 3.2). 

The order of bits and bytes within each description shall use the following notation unless otherwise stated: 

• In figures, the bit or byte shown in the left hand position is considered to be first. 

• In tables, the bit or byte shown in the left hand position is considered to be first. 

• In byte fields, the Most Significant bit (MSb) is considered to be first and denoted by the higher number. For 
example, the MSb of a single byte is denoted "hi" and the Least Significant bit (LSb) is denoted "bO". 

• In vectors (mathematical expressions), the bit with the lowest index is considered to be first. 

4 System conception for DRIVI coverage monitoring 

Current professional or monitoring DRM receivers are based on different architectures (see figure 4.1). To enable test 
equipment to be used for all of those receivers, the definition of a standardized interfacing protocol is necessary. To 
overcome the difficulties that the receiver implementations are based on different platforms a TCP/UPD/IP based 
approach is chosen. 

TCP/UDP/IP based 
standardised interface 



PC 



Frontend with DRIVI 
processing 



Interfacing 



PC 



Analogue 
Frontend 



Interfacing 
DRM Decoding 



• I • 



PC 



Interfacing 
Frontend DRM Decoding 



• I • 



TCP/IP 
UDP/IP 



TCP/IP 
UDP/IP 



TCP/IP 
UDP/IP 



Figure 4.1 : Different architectures of DRM monitoring receivers 
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The standardized interface features a uni- or bi-directional link for control and a uni-directional link for status 
information. Receiver Control information (RX_CTRL), like setting of the reception frequency or recording commands, 
are fed to a PC connected to the DRM decoder/receiver by the streaming orientated UDP/IP protocol or (more reliable) 
the connection orientated TCP/IP protocol. Receiver Status information (RX_STAT), like the received field strength, 
signal to noise ratios, audio status, bit error rates or even the received bit stream, are provided each DRM multiplex 
frame (all 400 ms) by the connected PC via the streaming orientated UDP/IP protocol. To ensure correct transmission 
and to encapsulate transmitted data, further protocol layers are added for control and status of the transmission. 

The basic principle of the set-up for a monitoring system is depicted in figure 4.2. All the distributed and automatically 
running remote DRM receivers are respectively connected to a computer dedicated to data collection. The DRM 
receiver and the data collector can certainly be one unit. The data collector evaluates the RSCI protocol stream coming 
from the DRM receiver, extracts the needed data and prepares this data for network transfer to the data analyser. The 
time slots to be monitored are signalled by the scheduler, which can be located at the same place as the data analyser or 
elsewhere. The central data analysis site collects the data uploaded by the different receivers in order to perform further 
analysis. 











http 
Network ) 
Email or DCP 


Scheduler 


DRM 
Receiver 


RSCI 


Data 
Collector 


IP 








Data 
Analyser 


\ 




/ 
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\ / 



Central Analysis Site 

Figure 4.2: Basic monitoring set-up 

The receiver is one part of such a system and if different receiver types provide standardized output and control 
functions, this simplifies the set-up. 



Protocols, profiles and rules 



5.1 



Protocols 



In order to enable easy exchange of different types of receivers in a test set-up two interfaces are defined for receiver 
status and control. A RSCI-compliant receiver shall provide one of those two interfaces: 

a) DCP TAG/AF layer via UDP/IP or TCP/IP for RX_CTRL and DCP TAG/AF layer via UDP/IP for 
RX_STAT. TCP/IP and UDP/IP shall be available either direct on a PC-based receiver or accessible by a PC. 

b) DCP TAG/AF layer via RS232 for RX_CTRL and RX_STAT. 

If a receiver has no TCP/IP and/or UDP/IP interface and no RS232 interface, the receiver may be extended by some 
kind of module (e.g. a PC), which provides the required interfaces. 

NOTE: When using the streaming orientated UDP/IP protocol for RX_CTRL, the user has to be aware of the 
problem which comes with every uni-directional protocol - the possibility that command packets could 
get lost without notice, especially if there is no possibility of monitoring the effects of sent commands. 

The DCP TAG/AF layer is described in detail in TS 102 821 [2]. 
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5.2 Profiles 



To ensure interoperability between different control, receiver and status units a mandatory subset of TAG items is 
required. As different scenarios may require different subsets, profiles are defined. 

Each profile defines: 

• TAG items, which shall be transmitted (RX_STAT) by a receiver unit; and 

• TAG items, which shall be evaluated (RX_CTRL) by a receiver unit. 

Those TAG items are called mandatory for this profile. 

Profiles for RX_STAT and RX_CTRL information may be mixed, so that a receiver may be capable of profile A for 
RX_STAT and profile B for RX_CTRL. There are five profiles for different requirements and bit rates: 

Profile A: normal profile (FAC, SDC, MSC, no pilots); 

Profile B: very low bit rate profile (no FAC, no SDC, no MSC, no pilots); 

Profile C: low bit rate profile (FAC, SDC, no MSC, no pilots); 

Profile D: high bit rate profile (FAC, SDC, MSC, pilots); 

Profile Q: QoSAM profile (TAG items needed for the QoSAM project). 

Tables 5.1 and 5.3 are to give an overview of all the TAG items out of the RSCI protocol, the byte size to be transmitted 
for each of these TAG items (TAG header plus TAG value) and their appearance in the different RX_STAT or 
RX_CTRL profiles. The size of the TAG header is always 8 bytes as specified in clause 6. Therefore the size of the 
useful TAG value is eight bytes smaller than the given TAG item size in the second column of these tables - this 
reduced value should now correspond with the TAG length given in the descriptions of the TAG items (see 
clauses 6.4. 1 to 6.4.5). TAG items which may have a TAG length of zero in dependence of the level of synchronization 
of the receiver (see clause 6.4 and the according descriptions of the TAG items) or other receiver settings are marked 
with *) in the TAG item size column of table 5.1. 

Table 5.2 provides an informative basis on the data rates to be expected for the individual RX_STAT profiles. For these 
data rate values it is not taken into account that some TAG items may sometimes have a TAG length of zero (see 
clause 6.4), but only the TAG item sizes given in table 5.1. 
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Table 5.1 : Overview of RXSTAT TAG items in profiles 



Name of TAG item 


Size of TAG item 


Profile A 


Profile B 


Profile C 


Profile D 


Profile Q 


*ptr RSCI 


1 6 bytes 


■/ 


• 


• 


• 


■/ 


*ptr DMDI 


1 6 bytes 


• 


X 


X 


,/ 


X 


difc 


1 2 bytes 


^ 


■/ 


• 


• 


• 


rpro 


9 bytes 


^ 


■/ 


■/ 


■/ 


y 


fmjd 


1 6 bytes 


^ 


,/ 


V 


,/ 


^ 


time 


33 bytes 


optional 






optional 




rgps 


34 bytes *) 


V 






V 




rdmo 


1 2 bytes 


V 


,/ 


,/ 


,/ 


^ 


rfre 


12 bytes*) 


^ 


■/ 


■/ 


• 


/ 


rdbv 


min. 10 bytes 
max. 56 bytes *) 


^ 


•/ 


Y 


•/ 


^ 


rinf 


24 bytes 


^ 


,/ 


,/ 


,/ 


^ 


ract 


9 bytes 


y 


■/ 


■/ 


■/ 


y 


rsta 


1 2 bytes *) 


• 


■/ 


■/ 


• 


• 


rbw 


1 bytes *) 


,/ 


•/ 


y 


,/ 




rser 


9 bytes *) 


y 


■/ 


■/ 


■/ 


y 


rtty 


1 2 bytes *) 


^ 


,/ 


V 


,/ 


^ 


rafs 


1 4 bytes *) 


V 


■/ 


■/ 


• 


/ 


reas 


min. 13 bytes 
max. 1 8 bytes *) 


V 




■/ 


■/ 




robm 


9 bytes *) 


■/ 


■/ 


■/ 


■/ 


y 


fac 


1 7 bytes *) 


• 




^ 


,/ 


^ 


sdc_ 


min. 24 bytes 
max. 218 bytes*) 


■/ 




■/ 


■/ 




sdci 


min. 12 bytes 
max. 21 bytes *) 


V 




Y 


•/ 


V 


strO 


min. 32 bytes 
max. 9 028 bytes *) 


V 






,/ 




str1 


y 






■/ 




str2 


^ 






,/ 




str3 


V 






,/ 




rpil 


min. 213 bytes 
max. 2 948 bytes *) 








■/ 




rwmf 


1 bytes *) 


■/ 


■/ 


■/ 


■/ 


■/ 


rwmm 


1 bytes *) 


^ 


,/ 


,/ 


^ 


V 


rmer 


1 bytes *) 


,/ 


•/ 


•/ 


y 


^ 


rbpO 


1 2 bytes *) 


• 


■/ 


■/ 


■/ 




rbp1 


1 2 bytes *) 


V 


^ 


^ 


^ 




rbp2 


1 2 bytes *) 


■/ 


■/ 


■/ 


■/ 




rbp3 


1 2 bytes *) 


V' 


,/ 


• 


• 




rdel 


min. 1 1 bytes 
max. 38 bytes *) 


V 


,/ 


^ 


,/ 


^ 


rdop 


1 bytes *) 


V 


,/ 


^ 


/ 


,/ 


rpsd 


93 bytes or 
147 bytes*) 


V 






■/ 




*) TAG items may have a TAG lengtli of zero in dependence of the level of synchronization of the 
receiver or other receiver settings. 


^ = TAG item is mandatory for this profile. 
X = TAG item shall not be used in this profile. 



Table 5.2: Data rates of RX_STAT profiles 



Data rate of profile 


Profile A 


Profile B 


Profile C 


Profile D 


Profile Q 


IVIinimal data rate [bytes/frame] 


526 


285 


351 


739 


256 


Minimal data rate [bytes/s] 


1 315 


712,5 


877,5 


1 847,5 


640 


Maximal data rate [bytes/frame] 


9 890 


358 


632 


12 838 


338 


Maximal data rate [bytes/s] 


24 725 


895 


1 580 


32 095 


845 
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Table 5.3: Overview of RXCTRL TAG items in profiles 



Name of TAG item 


Size of TAG item 


Profile A 


Profile B 


Profile C 


Profile D 


Profile Q 


cact 


9 bytes 


■/ 


■/ 


■/ 


■/ 


■/ 


cfre 


12 bytes 


^ 


• 


V 


V 


^ 


cdmo 


1 2 bytes 


■/ 


y 


■/ 


y 


y 


cbws 


10 bytes 












cbwg 


1 bytes 












cser 


9 bytes 


• 


• 


■/ 


■/ 


■/ 


crec 


12 bytes 












■^ = AG item is mandatory for tliis profile 



TAG items 



For ease of reference, the basic structure of a TAG packet and the TAG items it contains is described in figure 6.1. 



TAG packet 



TAG item 



TAG item 


TAG item 


TAG item 




TAG item 


TAG padding 


' 




-*— < 8 bytes— *i 









Name 


Lengtin 


Value 


TAG item padding 



-4 bytes- 



-4 bytes- 

A 



-Length bits- 



-< 8 bits- 



Total length always a whole number of 8-bit bytes 

Figure 6.1 : TAG packet and TAG item overview 

The definition of the TAG layer is contained in detail in TS 102 821 [2], clause 5. The present document only contains a 
copy of the description out of TS 102 821 [2]. In the case of differences the description in TS 102 821 [2] is valid. All 
conventions and restrictions given in clauses 6.1 to 6.3 apply in addition to what is stated in TS 102 821 [2], clause 5. 



6.1 



Format of TAG items 



The TAG layer is part of the Application Framing (AF) layer and forms the interface between the application and the 
DCP protocol. For the exact definition of the TAG layer see TS 102 821 [2]. 

The TAG layer is used to multiplex multiple data streams into one data stream (it combines multiple TAG items to one 
TAG packet). Output of the TAG layer are TAG packets. Each TAG packet consists of a seamless list of TAG items. 
Each TAG item has the following structure: 

The TAG header contains a fixed portion of 8 bytes length, which includes the following information: 

• TAG name: a four-byte name in ASCII characters used to identify the data value carried in the TAG item. 

• TAG length: a four-byte value representing the number of bits in the TAG value field. 

The TAG value section contains the data for the respective TAG item, which shall always comprise a number of full 
bytes (n X 8 bits) and shall be in format of Most Significant bit (MSb) first in each byte. All numeric data shall be in 
network byte order (= big endian). 

• TAG value: any value as required by the application. 

NOTE: If the TAG length is not a multiple of 8 then the remaining bits of the last byte shall be padded with zero 
bits. The number of transmitted bytes is ((TAG length H- 7) mod 8). 

• TAG item padding: up to seven zero bits to make the total length of the TAG item a whole number of bytes. 
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6.2 Conventions for TAG names 

All TAG names defined for RX_STAT and RX_CTRL TAG items are lower case (all four characters). 

Except for additional proprietary TAG items each company may add - these TAG names shall start with a capital letter 
while the remaining three characters are again lower case. The naming conventions for these proprietary TAG items are 
defined in detail in TS xxx xxx [5], clause 5.2. For ease of reference table 6.1 gives a shortened overview of the 
available TAG name first letters for additional proprietary RSCI TAG items extracted from TS xxx xxx [5], clause 5.2, 
table 2. In the case of differences the description in TS xxx xxx [5] is valid. 

Table 6.1 : Naming of proprietary TAG items 



TAG name first letter 
(ASCII, upper case) 


To be used for proprietary TAG items by 


AtoT 


Already in use by individual DRIVI members or reserved for 
future assignment to individual DRIVI members 


U, V, W, X, Y, Z 


Freely available to be used by any DRIVI member 


0to9 


Freely available to be used by any person or organization 



TAG names starting with the asterisk character '*' belong to (application protocol independent) Control TAG items (see 
TS 102 821 [2], clause 5.2.2). 

6.3 General rules for the TAG layer 

All TAG items may have any order within the TAG Packet. 
Unknown TAG items shall be ignored by a parser unit. 

6.4 TAG items for RX_STAT 

The TAG items within the following sub clauses are defined for RX_STAT communication. 

Every 400 ms all TAG items are transmitted as one TAG packet even if the receiver is not synchronized to a DRM 
signal or the demodulation type is not 'DRM'. If the receiver gets synchronization the receiver may send a new TAG 
packet within less than 400 ms. The packets are sent regardless if there is a device listening or not (or indeed whether 
the receiver is tuned to a DRM signal or not). 

All mandatory TAG items shall be present in each TAG packet. All other TAG items may be present. 

If the TAG value of a TAG item has a fixed size then the size is given at the point TAG length. Some of the TAG items 
have variable data length due to a variable size of the TAG value. This is indicated by the expression "variable". The 
length is then given in the TAG value description. For some TAG items the TAG value may sometimes not be 
available. Such TAG items are marked by "or 0" at the point TAG length. 

EXAMPLE: If there is no FAC available because of demodulation type is 'AM' or due to no synchronization in 
demodulation type 'DRM' then the TAG length of TAG item 'fac_' is zero. 

The receiver shall fill in TAG items whenever the receiver has the TAG value available. The receiver is not allowed to 
leave out some of the TAG items which are mandatory for the chosen RX_STAT profile because of user selections or 
because the TAG value is not available. 



The communication is uni-directional. 
The data originates at the receiver. 



6.4.1 TAG items for protocol specification 

For ease of reference the definition for TAG item "*ptr" with protocol name "RSCI" is copied from TS 102 821 [2], 
clause 5.2. In the case of differences the description in TS 102 821 [2] is valid. 
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For ease of reference the definition for TAG items "dlfc" and "*ptr" with protocol name "DMDI" are copied from 
TS 102 820 [3], clause 5.1. In the case of differences the description in TS 102 820 [3] is valid. 



6.4.1.1 



Protocol type and revision (*ptr) 



It is highly recommended that every application using the DCP protocol should declare a protocol type and revision in 
every TAG packet using the "*ptr" TAG item as shown in figure 6.2a. This TAG item requires no TAG item padding 
and is mandatory for all RX_STAT profiles. 





rAG 


name 




TAG length 










TAG value 




ASCII *ptr 


64 bits 


Protocol Name 


Protocol Revision 


* 


p 


t 


r 


00ie 


00ie 


00ie 


40i6 


R 


S 


C 


1 


Major 


Minor 


■* 4 bytes- 


fc - /I V^,,t^r. 










" 




'' 






" 





Figure 6.2a: Protocol type and revision RSCI 

Protocol name: The ASCII string "RSCI" (Receiver Status and Control Interface) as the name of the protocol. 
Typically this will be encoded using ASCII values in the range 20^^ to TF^g, but values outside this range may be used 

if desired. 

Protocol revision, major: A binary counter representing the major version number of the protocol, starting from OOjg. 
The currently used value is 03 ^g. 

Protocol revision, minor: A binary counter representing the minor version number of the protocol, starting from OO^g. 
The currently used value is OO^g. 

For further information on the revision numbering refer to clause 6.6. 

In the cases of RX_STAT profiles A and D the RSCI protocol stream comprises all TAG items of the MDI protocol. 
Therefore these RSCI protocol streams may be understood as a MDI stream (with some additional TAG items unknown 
to a MDI-only capable device) if an extra control TAG item for the protocol type and revision of the MDI protocol is 
added as shown in figure 6.2b. This allows these RSCI protocol streams to be more flexible in further use: They may be 
taken as RSCI or MDI protocol streams depending on purpose and capability of the receiving device. 

This extra control TAG item "*ptr" with protocol name "DMDI" shall be present in addition to the one with protocol 
name "RSCI" (see above), but only in the cases of RX_STAT profiles A and D. For all other RX_STAT profiles the 
TAG item "*ptr" with protocol name "DMDI" is not allowed to be inserted because the RSCI protocol stream does not 
necessarily comprise all the TAG items needed for a MDI protocol stream. 





TAG 


name 




TAG length 










TAG value 




ASCII *ptr 


64 bits 


Protocol Name 


Protocol Revision 


* 


P 


t 


r 


00,6 


00,6 


00,6 


40i6 


D 


M 


D 


1 


Major 


Minor 



'!^ 4 bytes - 



-4 bytes - 



-4 bytes- 



-2 bytes'-r-2 bytes "i 
Figure 6.2b: Protocol type and revision MDI 
Protocol name: The ASCII string "DMDI" (DRM Multiplex Distribution Interface) as the name of the protocol 

Protocol revision, major: A binary counter representing the major version number of the protocol, starting from OOjg. 
The currently used value is OO^g. 

Protocol revision, minor: A binary counter representing the minor version number of the protocol, starting from OO^g. 
The currently used value is OO^g. 
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For further information on the revision numbering refer to TS 102 820 [3], clause 5.3 Revision history. 

6.4.1 .2 DRM logical frame count (difc) 

This TAG item, as shown in figure 6.3, shall be included in every RSCl TAG packet and is therefore mandatory for all 
RX_STAT profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII difc 


32 bits 


Logical Frame Count 


d 


1 


f 


c 


00i6 


00,, 


00,, 


20i6 


00,g...FFFFFFFF,3 



|-« 4 bytes - 



-4 bytes - 



-4 bytes - 



Figure 6.3: DRM logical frame count 

Logical frame count: 32-bit unsigned integer value as a data packet counter. 

The value of the counter shall be incremented by one for each TAG packet sent by the device generating the TAG 
packets. In the event that the maximum value is reached, the counter shall reset to zero: FFFFFFFE^g, FFFFFFFFj^, 
OOOOOOOOjg, 00000001 ,g, etc. The receiver shall not expect or require the first packet to have a specific value of the 
logical frame count. This counter shall be used by the receiving unit of the TAG packets to ensure that packets which 
arrive out-of-order are re-ordered correctly. The logical frame count may also be used to detect lost TAG packets and, if 
a suitable link exists, request re-transmission of the lost packets. 

NOTE: Due the length of 32 bits this counter covers a time span of about 54 years if one packet containing this 
TAG item is sent every 400 ms. 



6.4.1.3 



Type of RX_STAT profile (rpro) 



For analysis of the received RX_STAT profile and to know at the listening unit what information is provided within the 
actual protocol stream the name of the used profile shall be included using the "rpro" TAG item as shown in figure 6.4. 
Therefore this TAG item is also mandatory for all RX_STAT profiles. 



TAG name 



TAG length 



TAG value 



ASCII rpro 


8 bits 


Profile Type 


r 


P 


r 





00i6 


00i6 


00ie 


08ie 


A, B, C, DorQ 



-4 bytes - 



-4 bytes - 



-1 byte- 



Figure 6.4: Type of RX_STAT profile 
Profile type: ASCII character 'A', 'B', 'C', 'D' or 'Q' as name of the actual RX_STAT profile. 



6.4.1.4 



Fractional Modified Julian Date (fmjd) 



This TAG item holds the fractional Modified Julian Date (MJD) of the reception as shown in figure 6.5. The time 
describes as closely as possible the arrival of the first signals of the first symbol of the actual transmission frame at the 
Radio Frequency (RF) input of the receiver. If a receiver has no real time clock the time signalled in this TAG item 
should start with power on of the receiver. This TAG item is mandatory for all RX_STAT profiles. 
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TAG name 



TAG length 



TAG value 



ASCII fmjd 


64 bits 


Modified Julian Date 


Fractional Day 


f 


m 


J 


d 


00,6 


00,6 


00,6 


40^6 


00,6... 0001 FFFF,6 


00,6 - 337F97FF,6 



r^ 4 bytes - 



-4 bytes - 



-4 bytes - 



-4bytes- 



Figure 6.5: Fractional Modified Julian Date 



Modified Julian Date: 32-bit integer value (only 17 bits are used) for the MJD of the actual day. 
A conversion algorithm could look like this: 

/* move leap day virtual to end of year */ 

modif ied_month = ((month + 9) mod 12) + 3; /* month is 1 . . 12 */ 

modif ied_year = year -1+1 (month + 7) / 10 I; 

/* intermediate variables */ 
nl = fmodif ied_year / 1001; 



n2 = modif ied_year mod 100; 

JulianDate = 1721029 

+ 146097 * fnl / 41 
+ 36524 * (nl mod 4) 
+ 1461 * rn2 / 41 
+ 365 * (n2 mod 4) 
+ 30 * modif ied_month 



/* offset January, 1st 4713 BCE */ 

/* days of elapsed 400-year-cycles */ 

/* days of elapsed 100-year-cycles */ 

/* days of elapsed 4-year-cycles */ 

/* days of elapsed years */ 

/* days of elapsed months in actual year */ 



+ 1(7* (modif ied_month - 2) ) / 12 j /* days of unequal month-length */ 
+ day; /* elapsed days in actual month */ 



/* 


modification from JD to MJD is -2400000.5 */ 














/* 


08.10.2001 00:00:00 = 2452190.5 JD = 52190 


MJD 




(to integer) 


= 52190 


MJD 


*/ 


/* 


08.10.2001 12:00:00 = 2452191.0 JD = 52190 


5 MJD 




(round down) 


= 52190 


MJD 


*/ 


/* 

Mo 


08.10.2001 23:59:59 = 2452191.49999 JD = 52190 
lifiedJulianDate = JulianDate - 2400001; 


99999 


MJD 


(round down) 


= 52190 


MJD 


*/ 



NOTE 1: Today's (March P^ 2004) MJD is 53 065. With 17 bits we can go up to day 131 071, which corresponds 
to another 213 years. 

Fractional Day: the fractional day is the number of 1/10 ms that passed since midnight that day, using UTC time 

NOTE 2: There are 86 400 x 10 000 tenths of a millisecond a day which is approximately 2^^, so 32 bits are 
sufficient. 



6.4.1.5 



Time and date in ASCII notation (time) 



This TAG item has got the same function as the TAG item 'fmjd' above, but is in ASCII notation as shown in figure 6.6 
for readability when looking at the RSCI data stream with a simple text editor. Because this TAG item does not give 
any information beyond the 'fmjd' TAG item, it is only optional for the both high data rate RX_STAT profiles A and D. 





TAG 


name 




TAG length 




TAG value 


ASCII time 


200 bits 


Date/Time in ASCII notation 


t 


i 


m 


e 


00,6 


00,6 


00,6 


C8,6 


YYYY-MM-DDTHH:MM:SS.FFFFZ 



r* 4 bytes - 



-4 bytes - 



-25 bytes- 



Figure 6.6: Time and date in ASCII notation 
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Date and time information is provided in ASCII notation 'YYYY-MM-DDTHH : MM : SS . FFFFZ' with: 

YYYY year 

MM month (January = '01'... December = '12') 

DD day (starting with '0 1' at first day of each month) 

T the letter 'T' as separator 

HH hour 

MM minutes 

S S seconds 

FFFF fractional seconds with a resolution of 0,1 ms 

Z the letter 'Z' for Zero Median (i.e. UTC) 

EXAMPLE: 2004-03-01112:34:56. 7890Z stands for March 1 **' 2004, 34 minutes and 56,7890 seconds 

past 12 UTC. 



6.4.1.6 



GPS information (rgps) 



This TAG item gives information on the position and movement of the receiver using the GPS satellite positioning 
system as shown in figure 6.7. If no GPS information is available an empty TAG item shall be transmitted. This TAG 
item is mandatory for RX_STAT profiles A and D. 





TAG 


name 




TAG length 






TAG value 




ASCII time 


208 bits or 


GPS Information 


r 


g 


P 


s 


00ie 


00ie 


00ie 


D0,6 


Position 


Time and Date 


Movement 



-4 bytes- 



-4 bytes - 



-26 bytes- 



SVDDMFFDDMFFAAF 


HMSYYMD 


SSCC 



-15 bytes- 



••—7 bytes— ^4 bytes "^ 



Figure 6.7: GPS information 



The positioning information shall be acquired using the WGS84 grid, to allow the use of other positioning systems 
beside GPS. This information is written to the TAG value in the following format 'SVDDMFFDDMFFAAF' with: 

S source of the position data as 8-bit unsigned integer value with the meanings listed below 



V 

Latitude 

DD 

M 

FF 

EXAMPLE 1: 
EXAMPLE 2: 



-16 



invalid 
GPS receiver 
differential GPS receiver 



3jg manual entry 
FFjg not available 
number of satellites in view as 8-bit unsigned integer value 
FFjg not available 

latitude value as DD degrees, (M H- FF / 2^^) minutes north or south 
FFFF_FF_FFFFjg if not available 

latitude degrees as 16-bit signed integer value with positive values mean north and negative values 

mean south 

latitude minutes as 8-bit unsigned integer value 

latitude fractional minutes as 16-bit unsigned integer value 

DDMFF = 002F_04_3F92jg means latitude = 47° 4.24832' North 
DDMFF = FFFE_22_9F92i6 means latitude = 2° 34.62332' South 
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NOTE 1 : If you want to create a floating point value for the latitude the following code can be used: 

if (degree >= 0) { 

latitude = degree + (minutes + fractional / 65536) / 60; 
} else { 

latitude = degree - (minutes + fractional / 65536) / 60; 



} 



Longitude 

DD 

M 

FF 



longitude value as DD degrees, (M + FF / 2^^) minutes east or west 

FFFF_FF_FFFFjg if not available 
longitude degrees as 16-bit signed integer value with positive values mean east and negative 
values mean west 

longitude minutes as 8-bit unsigned integer value 
longitude fractional minutes as 16-bit unsigned integer value 



EXAMPLE 3: DDMFF = 00AA_04_3F92i6 means longitude = 170° 4.24832' East 

EXAMPLE 4: DDMFF = FFFE_22_9F92i6 means longitude = 2° 34.62332' West 

NOTE 2: If you want to create a floating point value for longitude the following code can be used: 

if (degree >= 0) { 

longitude = degree + (minutes + fractional / 65536) / 60; 
} else { 

longitude = degree - (minutes + fractional / 65536) / 60; 



Altitude altitude value as (AA +¥ 1 256) in meters above sea level 

FFFF_FF2g if not available 

AA altitude meters as 16-bit signed integer value 

F altitude fractional meters as 8 -bit unsigned integer value 

EXAMPLE 5: AAF = 0123_DFjg means altitude = 291.871 meters above sea level 
EXAMPLE 6: AAF = FFFE_DFjg means altitude = 1. 12890 meters below sea level 

NOTE 3: If you want to create a floating point value for altitude calculate (AA +¥ 1 256). 

NOTE 4: This is the same as to put 'AA' and 'F' into a signed 24-bit integer value ('AA' is the higher part) or into the 
lower three bytes of a signed 32-bit integer value ('AA' is the higher part, setting the MSB to OOjg or FF^g 

whether 'AA' is positive or negative) and to divide this value by 256. 
GPS date and time information is provided in the following format 'HMSYYMD' with 



Time: 

H 
M 
S 

Date: 

YY 
M 

D 



hours (24h format), minutes and seconds in UTC time 

FF_FF_FFjg if not available 
hours as 8-bit unsigned integer value 
minutes as 8-bit unsigned integer value 
seconds as 8 -bit unsigned integer value 

year, month and day 

FFFF_FF_FF2g if not available 
year as 16-bit as unsigned integer value 

number of month as 8-bit unsigned integer value (January = 1 jg ■■■ December = 12jq) 
number of day as 8-bit unsigned integer value (starting with 1 jq at first day of each month) 



Movement information is provided in the following format 'SSCC' with 

Speed: speed over ground as (SS / 10) in [m/s]; a stationary receiver should set speed to 

SS 
Heading: 

CC 



FFFFjg if not available 
speed data as 16-bit unsigned integer value 



heading degrees clockwise from north [0; 360[; a stationary receiver should set heading to 

FFFFjg if not available 
heading data as 16-bit unsigned integer value 
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6.4.2 TAG items specifying tine transmission 

The following TAG items are to specify the demodulation type of the current received transmission and at which 
frequency and signal strength this transmission is received. 



6.4.2.1 



Receiver demodulation type (rdmo) 



This TAG item holds the receiver's actual demodulation type in ASCII notation as shown in figure 6.8 and is mandatory 
for all RX_STAT profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII rdmo 


32 bits 


Receiver Demodulation Type 


r 


d 


m 





00ie 


00ie 


00,, 


20^6 


drm_, am , usb_, lsb_ or sam_ 



!-* 4 bytes - 



-4 bytes - 



-4 bytes - 



Figure 6.8: Receiver demodulation type 

The information of the actual demodulation type of the receiver is given as four ASCII characters: 

drm_ DRM demodulation 

am AM demodulation 

usb_ Upper Side Band demodulation 

lsb_ Lower Side Band demodulation 

s am_ Synchronous AM demodulation 

6.4.2.2 Reception frequency (rfre) 

If this information is available for the unit generating the RSCI protocol stream, the reception frequency of the current 
transmission should be signalled using the 'rfre' TAG item as shown in figure 6.9. In case that the frequency information 
is not available to the unit generating the RSCI protocol stream, an empty TAG item shall be inserted. This TAG item is 
mandatory for all RX_STAT profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII rfre 


32 bits or 


Reception Frequency 


r 


f 


r 


e 


00,, 


00,, 


00„ 


20i6 


00„...FFFFFFFF,g 



'r^ 4 bytes - 



-4 bytes - 



-4 bytes - 



Figure 6.9: Reception frequency 
Reception frequency: 32-bit unsigned integer value in [Hz]. 



6.4.2.3 



Received signal strength (rdbv) 



The following TAG item is used to include the Root Mean Square (RMS) of the received signal strength within the 
bandwidth occupied by the DRM signal into the protocol stream as shown in figure 6.10. Several signal strength values 
may be included in this TAG item, which is mandatory for all RX_STAT profiles. If no signal strength information is 
available an empty TAG item shall be transmitted. 
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TAG 


name 


TAG length 




TAG value 




ASCII rdbv 


16nbitsor0 
with n= 1 ... 24 


n Signal Strength Values 


r 


d 


b 


V 


Value 1 


Value 2 




Value n 





















Byte1 



Byte2 



Figure 6.10: Received signal strength 
Signal strength value: the format of a single value is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [dB|iV] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE 1: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 

The measurement time of each signal strength value is the length of a DRM transmission frame (400 ms) divided by the 
number of values in the TAG item, which can be calculated by (400 ms / ('rdbv' TAG length / 16)). The suggested 
measurement time for one signal strength value is one DRM transmission frame, which results in the minimum number 
of one value per TAG item. The maximum number of signal strength values is one per OFDM symbol, which results in 
the maximum number of 24 values per TAG item if transmission mode D is received. 

The unit [dB|iV/m] is used to indicate the field strength (which is independent of the antenna factor) in contrast to 
[dB|iV] which is commonly used for the signal strength (which is dependent of the antenna factor). It is easy to estimate 
the field strength by just adding the antenna factor (usually a few dB) to the signal strength. 

NOTE 2: (value in [dB|aV]) = (value in 0[dBm]) + 107 dB in case of receiver input impedance of 50 Q.. 

6.4.3 TAG items specifying receiver settings 

The following TAG items are to specify the type and status of the currently used receiving equipment. 

6.4.3.1 Receiver type (rinf) 

To provide information about the used receiver - manufacturer, type, version and serial number - the following TAG 
item is used as shown in figure 6.11. This TAG item is mandatory for all RX_STAT profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII rinf 


128 bits 


Receiver Type, Version, Serial 


r 


i 


n 


f 


00i6 


00i6 


00i6 


80,6 


RRRRFFMMNNSSSSSS 



j-* 4 bytes - 



-4 bytes - 



-16bytes- 



Figure 6.1 1 : Receiver type 
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Receiver type, version number and serial number are provided in ASCII notation 'RRRRFFMMNNSSSSSS' with: 



RRRR 



FF 
MM 
NN 
SSSSSS 



is used to identify the receiver manufacturing company. Yet defined are 

bbc_ by use of BBC British Broadcasting Corporation 

fhg_ by use of FhG Fraunhofer Gesellschaft 

thai by use of Thales Broadcast & Multimedia 
is set to identify different receiver implementations of this company 
major revision number in two ASCII characters 
minor revision number in two ASCII characters 
serial number of the decoder in six ASCII characters (number characters are from '0' to '9') 



6.4.3.2 



Receiver activated (ract) 



If the receiving equipment is activated or deactivated for reception is signalled by the following TAG item as shown in 
figure 6.12. This TAG item is mandatory for all RX_STAT profiles. 



TAG name 



TAG length 



TAG value 



ASCII ract 


8 bits 


Receiver Activated 


r 


a 


c 


t 


00i6 


00,6 


00i6 


08,6 


ASCII '0' or '1' 



!-* 4 bytes - 



-4 bytes - 



-1 byte- 



Figure 6.12: Receiver activated 
Receiver activated: this ASCII character gives the active status of the reception equipment as follows: 



ASCII' 0' 
ASCII' 1' 



deactivated 
activated 



6.4.3.3 



Status of receiver (rsta) 



The following TAG item as shown in figure 6.13 gives information on the receiver status in terms of the decoding 
process. If the demodulation type of the receiver is not 'DRM', an empty TAG item shall be transmitted. This TAG item 
is mandatory for all RX_STAT profiles. The audio decoding status byte of the TAG value relates to the actual selected 
service (see clause 6.4.3.5). 





TAG 


name 




TAG length 






TAG value 




ASCII rsta 


32 bits or 


Status of Receiver 


r 


s 


t 


a 


00,6 


00,6 


00,6 


20,6 


Sync 


FAC 


SDC 


Audio 



'r^ 4 bytes - 



-4 bytes - 



-4 bytes - 



00,6 or 01 ^g 



FF 



16 



Figure 6.13: Status of receiver 

Status of receiver: Four bytes, treated as 8-bit unsigned integer values, are indicating the status of the four main 
decoding stages. Positive values are standing for an error at that stage while zero means everything ok. 

• Status of synchronization: A positive value shall be set while there is no synchronization to a DRM signal or 
while the synchronization is in progress but not yet finished. 

• Status of FAC decoding: A positive value shall be set if the CRC of the actual FAC block is not correct or if 
other decoding problems like not allowed values are detected. 
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Status of SDC decoding: A positive value shall be set if the CRC of the actual SDC block is not correct or if 
other decoding problems like not allowed values or corrupted data entities are detected. 

Status of audio decoding: A positive value shall be set if one or more audio frames are corrupted within one 
DRM multiplex frame or even if no audio frames are available. 



6.4.3.4 



IF filter bandwidth (rbw_) 



The following TAG item holds the bandwidth of the input IF filter of the receiver as shown in figure 6.14. If no IF filter 
bandwidth information is available an empty TAG item shall be transmitted. This TAG item is mandatory only for 
RX_STAT profiles A, B, C and D. 





TAG 


name 




TAG length 




TAG value 


ASCII rbw_ 


16 bits or 


IF Filter Bandwidth 


r 


b 


w 


— 


00,, 


00i6 


00i6 


10i6 


Byte1 


Byte 2 



'r^ 4 bytes - 



-4 bytes - 



-2 bytes - 



Figure 6.14: IF filter bandwidth 
IF filter bandwidth: the format is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [kHz] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 



6.4.3.5 



Selected service (rser) 



The actual selected service at the GUI is given by the following TAG item as shown in figure 6.15. This information is 
important in order to know which service the audio status (see clauses 6.4.3.3, 6.4.3.7 and 6.4.3.8) belongs to. Therefore 
this TAG item is mandatory for all RX_STAT profiles. If the receiver is not in synchronization, an empty TAG item 
shall be transmitted. 





TAG 


name 




TAG length 




TAG value 


ASCII rser 


8 bits or 


Selected Service 


r 


s 


e 


r 


00i6 


00i6 


00i6 


08i6 


FF,6 0rO,o...3,o 



I-* 4 bytes - 



-4 bytes- 



-1 byte- 



Figure 6.15: Selected service in GUI 
Selected service: 8-bit signed integer value specifying the short Id (0 to 3) of the selected service or FF^g if none. 
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6.4.3.6 



Received test type (rtty) 



To specify the content of the MSC data stream in terms of special content for test & measurement (see clause 7) the 
following TAG item is used as shown in figure 6.16. This TAG item is mandatory for all RX_STAT profiles. If no 
MSC data is available, an empty TAG item shall be transmitted. 



TAG name 



TAG length 



TAG value 



ASCII rtty 


32 bits or 


Received Test Type 


r 


t 


t 


y 


00,e 


00,6 


00i6 


20i6 


Stream 


Stream 1 


Stream 2 


Stream 3 



'!^ 4 bytes - 



-4 bytes - 



-4 bytes - 







10 ■ 



'10 



Figure 6.16: Received test type 
Received test type: four bytes (one for each stream Id) specifying the content of an MSC stream as follows: 



'10 
■10 
= 10 



'10 



stream is not available 
stream holds no test content 
stream contains synchronous PRBS 
stream contains asynchronous PRBS 



The first byte of the TAG value holds the received test type for the MSC stream with stream Id 0, ..., the fourth byte 
holds the received test type for the MSC stream with stream Id 3. 



6.4.3.7 



Audio status (rafs) 



This TAG item is used to signal the status of the audio decoder with a time base of one audio unit as shown in 
figure 6.17. Because of the importance of this information this TAG item is mandatory for all RX_STAT profiles. The 
given TAG value relates to the actual selected service (see clause 6.4.3.5). Whenever no audio units are available (e.g. if 
no audio service is selected or if no MSC data is available) then the TAG length of the TAG item 'rafs' shall be zero. 





TAG 


name 




TAG length 




TAG value 


ASCII rafs 


48 bits or 


Audio Status 


r 


a 


f 


s 


00,6 


00,6 


00,6 


30,6 


No. Audio Units 


Error Flags 



-4 bytes - 



-4 bytes - 



-1 byte- 



-5 bytes - 



5,6or10,6 



00,6 ■■■ FFC0000000,6 



Figure 6.17: Audio status 
No. audio units: number of audio units per DRM multiplex frame, which is 5 or 10. 

An audio unit is defined here to contain 1, 2 or 4 audio frames and covers 40 ms in time for MPEG-4 AAC with 24 kHz 
sampling rate, CELP and HVXC coding. Only for MPEG-4 AAC coding with 12 kHz sampling rate one audio unit 
contains one audio frame with 80 ms duration. This results in 10 respectively 5 error flags for each DRM multiplex 
frame of 400 ms length. For details of the audio coding used in the DRM system see ES 201 980 [1], clause 5. 
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Error flags: binary-coded audio status with one bit representing one audio unit filled from MSb of the second byte of 
the TAG value, holding the status of the first audio unit of the DRM multiplex frame. Zeros are padded from the right 
beginning at the LSb of the last byte. The used values for the error flags have the following meaning: 

O2 audio unit is ok 

1 2 audio unit is corrupted 

NOTE: The extensive padding of the error flags section is done, to be flexible in future use of this TAG item: The 
maximum number of audio sub frames per DRM multiplex frame is 40 (in case of MPEG-4 CELP 
coding) and therefore the error flags section of this TAG item is defined to be big enough to comprise all 
error flags in the case of one error flag per audio sub frame. 



6.4.3.8 



Extended Audio Status (reas) 



In addition to the TAG item 'rafs' above (see clause 6.4.3.7) the status of the audio decoder could be given a little bit 
more in detail using the TAG item 'reas' as shown in figure 6.18. This TAG item is mandatory for the higher datarate 
RX_STAT profiles A, C and D only. The given TAG value relates to the actual selected service (see clause 6.4.3.5). 
Whenever no audio units are available (e.g. if no audio service is selected or if no MSC data is available) then the TAG 
length of the TAG item 'reas' shall be zero. 





TAG 


name 


TAG length 




TAG value 




ASCII reas 


Snbits or 
with n = 5 or 10 


Audio Status 


r 


e 


a 


s 


Value 1 


Value 2 




Value n 


-* 4 bytes - 


i 








■" 1- uyioo "■ 









C 


rfu 


rfu 


UHS 


SBR 


SE1 


SE2 


ULS 



Figure 6.18: Extended audio status 

Audio status values: 8-bit unsigned integer value specifying the status of one audio unit with eight separate error flags 
as explained below. A classification of errors may be done in the following way: 



00 
01 



OF 



16 
IO16-FF16 



audio unit is ok 

audio unit is corrupted, but the errors are only located within the less sensitive part 

audio unit is corrupted, errors are located within the high sensitive part and maybe also within the 

less sensitive part 



One byte of error status shall be provided by the audio decoder for each audio unit. An audio unit is defined here to 
contain 1, 2 or 4 audio frames and covers 40 ms in time for MPEG-4 AAC with 24 kHz sampling rate, CELP and 
HVXC coding. Only for MPEG-4 AAC coding with 12 kHz sampling rate one audio unit contains one audio frame with 
80 ms duration. This results in 10 respectively 5 bytes of error status for each DRM multiplex frame of 400 ms length. 
For details of the audio coding used in the DRM system see ES 201 980 [1], clause 5. 

C (core CRC error flag): for MPEG-4 AAC and CELP coding this is the error status of the CRC check concerning the 
core data part; for MPEG-4 HVXC coding this is the error status of the CRC check concerning the ESCO data part of 
the audio unit. 

rfu: these two bits are reserved for future use and shall have the value zero. 

UHS (Unspecified High Sensitive error flag): decoder dependent error flag for all other detected errors within the 
high sensitive data part of the audio unit. 

SBR (SBR CRC error flag): error status of the CRC check concerning the SBR data part of the audio unit. 
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SEl (spectral data error flag no. one): for MPEG-4 AAC coding this is the error status of the spectral data part (in 
case of stereo coding only of the left channel spectral data part); for MPEG-4 CELP coding this flag is not used and 
shall have the value zero; for MPEG-4 HVXC coding this is the combined error status of the CRC check concerning the 
ESCl, ESC2 and if present ESC3 data part of the audio unit. 

SE2 (spectral data error flag no. two): for MPEG-4 AAC stereo coding this is the error status of the right channel 
spectral data part; for MPEG-4 AAC mono, CELP and HVXC coding this flag is not used and shall have the value zero. 

ULS (Unspecified Less Sensitive error flag): decoder dependent error flag for all other detected errors within the less 
sensitive part of the audio unit. 

NOTE: The error flags 'C, 'SBR' and in case of MPEG-4 HVXC coding also 'SEl' refer only to the pure CRC 
checks. Errors, that are located within the area protected by the CRC, but are detected otherwise in spite 
of apparently correct CRC, shall be signalled by the 'UHS' or 'ULS' error flags. For MPEG-4 AAC coding 
there exist two additional error flags for these unspecified errors to be a little bit more precise in terms of 
the error position. 

This more detailed differentiation of errors within an audio unit is done, because errors which are located within the less 
sensitive part of the audio data can be concealed in many cases by the source decoding process in a way that they are 
possibly not recognized by a human listener. But errors which are located within the high sensitive data part will be 
audible in nearly all cases. 

6.4.4 TAG items specifying DRM multiplex 

For ease of reference the definition for TAG items 'robm', 'fac_', 'sdc'_, 'sdci', 'strO', 'strl', 'str2' and 'str3' are copied from 
TS 102 820 [3]. In the case of differences the description in TS 102 820 [3] is vaHd. 



6.4.4.1 



Robustness mode (robm) 



This TAG item, as shown in figure 6.19, shall be included in every RSCI TAG packet and is therefore mandatory for all 
RX_STAT profiles. If the receiver is not in synchronization an empty TAG item shall be transmitted. 





TAG 


name 




TAG length 




TAG value 


ASCII robm 


8 bits or 


Robustness Mode 


r 





b 


m 


00,6 


00,6 


00,6 


08,6 


00,6 ...03,6 



|-* 4 bytes - 



-4 bytes - 



-1 byte- 



Figure 6.19: Robustness mode 

Robustness mode: the current robustness mode as detected by the decoding algorithms. 

The TAG value shall be encoded as given in table 6.2. All other values are reserved for future use. 

Table 6.2: Robustness mode encoding 



Value 


Robustness 


00,6 


Mode A 


01l6 


Mode B 


02i6 


ModeC 


03,6 


Mode D 



6.4.4.2 



Fast Access Channel (fac_) 



This TAG item as shown in figure 6.20 holds the complete FAC information as transmitted in the DRM multiplex and 
shall be included in every RSCI TAG packet. If no FAC information is available an empty TAG item shall be 
transmitted. This TAG item is mandatory for RX_STAT profiles A, C, D and Q. 
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TAG 


name 




TAG length 






TAG value 




ASCII fac_ 


72 bits or 


Channel 
Parameters 


Service 
Parameters 


CRC 


f 


a 


c 


— 


00,e 


00i6 


00,6 


48i6 



-4 bytes - 



-4 bytes - 



-20 bits- 



-•—44 bits- 
-9 bytes — 



h8 bits*i 



A 



Figure 6.20: Fast Access Channel 
Channel parameters: channel parameter section of the FAC as described in ES 201 980 [1], clause 6.3.3. 

Service parameters: service parameter section of the FAC as described in ES 201 980 [1], clause 6.3.4 (the data 
carried in the service parameters section shall be repeated according to the FAC repetition rules described in 
ES201 980 [1], clause 6.3.6). 

CRC: checksum over the previous part of the TAG value as described in ES 201 980 [1], clause 6.3.5. 



6.4.4.3 



Service Description Channel (sdc_) 



As shown in figure 6.21 this TAG item holds one complete SDC block as transmitted in the DRM multiplex and shall 
be included in the TAG packet containing the data for the first logical frame of each super frame. The TAG length of 
this TAG item in any other TAG packets shall be zero. Because of the data rate this TAG item is mandatory only for 
RX_STAT profiles A, C, and D. 





TAG 


name 


TAG length 






TAG value 






ASCII sdc_ 


(8n + 24) bits or 


Service Description Channe 


Block 


s 


d 


c 


— 


rfu 


AFS 


SDC Data 


CRC 


■* 4 bytes *• 




-*-4 bits*t*-4 bits*- 

d I r 






^1 fi hitcfc. 


, . ON l^,,t^^ 












4 














Figure 6.21 : Service Description Channel 
rfu: these four bits are reserved for future use and shall have the value zero. 

NOTE 1 : Bits to 3 (most significant bits of the first byte of the TAG value which are bit positions 4 to 7 of the 
first byte) are padded with zeros to keep the byte alignment of the rest of the SDC data block. 

Alternative Frequency Switching (AFS): index as described in ES 201 980 [1], clause 6.4.2. 

SDC Data: data block of the SDC as described in ES 201 980 [1], clause 6.4.3. 

CRC: checksum on the previous parts of the TAG value as described in ES 201 980 [1], clause 6.4.2. 

The size of the SDC data block (value of n) depends upon the robustness mode, constellation diagram used for SDC 
cells and spectrum occupancy of the DRM ensemble as described in ES 201 980 [1], clause 6.4.2, table 61 which lists 
values in the range of 13 to 207. 

NOTE 2: If an SDC block is present in the actual transmission frame then the TAG length is calculated by 
(1 byte + SDC data size (in bytes) + 2 bytes CRC) otherwise the TAG length is zero. 
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6.4.4.4 



Service Description Channel information (sdci) 



The following TAG item provides the SDC multiplex description data entity - type as shown in figure 6.22 and thus 
contains the complete multiplex description data of the DRM multiplex. This TAG item shall be included in every RSCI 
TAG packet of protocol streams using RX_STAT profiles A, C, D, and Q. If an TAG item 'sdc_' was sent, the TAG 
item 'sdci' shall be transmitted also in the two frames where an empty TAG item 'sdc_' is transmitted (second and third 
transmission frame of a super frame). 



TAG name 



TAG length 



TAG value 



ASCII sdci 



(24n + 8) bits or 



Protection 



rfu 



PLA 



PLB 



n Stream Description(s) 



Description 



Description 3 



j-* 4 bytes - 



-4 bytes- 



-4/2/2 bits- 



—3 bytes — ►i 
-(3n+ 1) bytes - 



-3 bytes - 



Figure 6.22: Service Description Channel information 

rfu: these four bits are reserved for future use and shall have the value zero. 

NOTE: Bits to 3 (most significant bits of the first byte of the TAG value which are bit positions 4 to 7 of byte 0) 
are padded with zeros to keep the byte alignment of the rest of the SDC data entity block. 

PLA and PLB: protection level as described in [1], clause 7.5.1. 

Stream description: stream description for an individual MSC stream as described in [1], clause 6.4.3.1. 

The first three-byte group holds the stream description for stream Id 0, ..., the fourth three-byte group holds the stream 
description for stream Id 3. Up to four stream descriptions may be included, the corresponding stream data is being 
carried in the RSCI 'strO', 'strl', 'str2' and 'str3' TAG items respectively (see clause 6.4.4.5). 



6.4.4.5 



MSC stream data <n> (strO, str1 , str2 and str3) 



The TAG items 'strO', 'strl', 'str2' and 'str3' shall contain the MSC data for the corresponding DRM stream as shown in 
figure 6.23. If the TAG length is zero, the TAG item may be omitted from the TAG packet. Because of data rate reasons 
these TAG items are mandatory only for RX_STAT profiles A and D. 





TAG 


name 


TAG length 


TAG value 


ASCII str? 


8n bits or 


MSC Stream Data 


s 


t 


r 


? 


"(00,6 - FF^e) 



'r* 4 bytes - 



-4 bytes - 



-n bytes - 



with ? = ... 3 



Figure 6.23: IVISC stream data 

The specific MSC stream is referred by use of the TAG name 'strO', 'strl', 'str2' or 'str3' appropriate to the stream Id. 

MSC stream data: the content of one specific MSC stream present in the DRM multiplex. 

The TAG length is the size of the MSC stream data in bits transported within one multiplex frame. 
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6.4.4.6 



Gain reference pilots (rpil) 



The cell values of the gain reference pilots are transported within an RSCI protocol stream using the TAG item 'rpil' as 
shown in figure 6.24. This TAG item is mandatory for RX_STAT profile D only because of the needed data rate, but 
shall be filled as soon as the FAC can be decoded. While the receiver is synchronizing or if the receiver is even not in 
synchronization an empty TAG item shall be transmitted. 



TAG name 



TAG length 



TAG value 



ASCII rpil 



-4 bytes - 



(8n + 32) bits or 



Gain Reference Pilot Information 



SN 



SR 



rfu 



Symbol 



Symbol 1 



-4 bytes - 



- 1/1/2 bytes - 



-n bytes - 



Symbol n-1 



PN 


PO 


BE 


li 


Qi 



Q. 



-3 bytes - 



-2/(bytes- 



Figure 6.24: Gain reference pilots 
SN (Symbol Number): number of symbols in this transmission frame as 8-bit unsigned integer value. 
SR (Symbol Repetition): amount of symbols until the pilot pattern repeats as 8-bit unsigned integer value. 
rfu: these two bytes are reserved for future use and shall have the value zero. 

The values of the gain reference pilot cells are listed in the following pattern grouped by symbols ... n-1 of one 
transmission frame: 

PN (Pilot Number): number of pilots k in the actual symbol as 8 -bit unsigned integer value. 

PO (Pilot Offset): offset of the first pilot in relation to the lowest carrier number used in the actual robustness mode 
and spectrum occupancy as 8-bit unsigned integer value. 

BE (Block Exponent): block exponent for all k pilot cell values of the actual symbol as 16-bit signed integer value. 

Il» Qp — » Ik» Qk- inphase and quadrature component of the received pilot cell values in order of the lowest to the 
highest carrier number as 16-bit signed integer values each. 

The pilot cell values that are sent in this TAG item are the received pilot cell values, after the phase rotations and gain 
boosting applied in the modulator have been removed. No channel estimation is applied. In other words, a perfect 
receiver receiving a perfect transmission without any channel effects and distortion would only output pilot cell values 
of absolute value 1 due to the overall scaling factor. 

The normalized pilot cell values can be re-calculated as: 

I[symbol, carrier] / 32768 • 2(Wock_exponent[Symbol]) + j . Q[symbol, carrier] / 32768 • 2(bl°ck_exponent[Symbol]) 

In order to insure the highest resolution I^, Q^, ..., Ij^, Qj^ should be as close to +32161 or -32768 as possible. 

NOTE 1 : Where a frequency reference cell occupies a slot in the gain reference pattern, that pilot cell value shall 
also be output. 

NOTE 2: A special case shall apply for the DC carrier of mode D: In symbols number 2, 5, 8, 11, 14, 17, 20, 23 a 
pilot with inphase and quadrature component value has to be added at this position. 
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EXAMPLE 1: Taking robustness mode D, spectrum occupancy parameter 3 (= 10.0 kHz of channel bandwidth) 
as an example (see ES 201 980 [1], annex L), and using notation [symbol, carrier] the data stream 
would be: 



24 



EXAMPLE 2: 



10 

Oio 

30io 

Oio 
BE[0] 



(8-bit unsigned integer: symbol number) 
(8-bit unsigned integer: symbol repetition) 
(2 byte reserved) 

(8-bit unsigned integer: pilot number) 
(8-bit unsigned integer: pilot offset) 
(16-bit signed integer: block exponent) 

I[0, -*4] Q[0, -44] I[0, ^1] Q[0, ^1] 

... I[0, -2] Q[0, -2] I[0, 1]Q[0, 1] 

... I[0, 40] Q[0, 40] I[0, 43] Q[0, 43] 

30jQ (8-bit unsigned integer: pilot number) 

1 jQ (8-bit unsigned integer: pilot offset) 

BE[1] (16-bit signed integer: block exponent) 

I[l, ^3] Q[l, ^3] I[l, ^0]Q[1, ^0] 

...I[1,-1]Q[1,-1]I[1,2]Q[1,2] 

... 1[1, 41] Q[l, 41] 1[1, 44] Q[l, 44] 



29 



10 



-10 



(see note 2 for this special case) 



(8-bit unsigned integer: pilot number) 
(8-bit unsigned integer: pilot offset) 
BE[2] (16-bit signed integer: block exponent) 

I[2, ^2] Q[2, ^2] 1[2, -39] Q[2, -39] 
... I[2, -3] Q[2, -3] I[2, 0]=0 Q[2, 0]=0 1[2, 3] Q[2, 3] 
... I[2, 39] Q[2, 39] 1[23, 42] Q[23, 42] 
30jQ (8-bit unsigned integer: pilot number) 

OjQ (8-bit unsigned integer: pilot offset) 

BE[3] (16-bit signed integer: block exponent) 

... and so on for symbols number 3 to 24 ... 

The maximum (worst case) data rate for the TAG item 'rpil' is achieved with robustness mode D, 
spectrum occupancy 5 (= 20.0 kHz) with 1 432 gain reference pilot cells per transmission frame. 

1 • 32 bits (symbol number, symbol repetition, reserved bytes) 

+ 24 (symbols/frame) • 32 bits (pilot number, pilot offset, block exponent) 

+ 1 432 (pilot cells/frame) • 2 (1 and Q) • 16 bits (pilot cell value) 

= 46 624 bit/frame 

46 624 bit/frame / 0,4 s (duration of transmission frame) =116 560 bit/s 



6.4.5 TAG items for results of measurements 

The following TAG items are to transport the outcome of measurements for modulation and bit error rates, delay and 
doppler estimation and power spectral density. 



6.4.5.1 



Weighted Modulation Error Ratio for FAC cells (rwmf) 



This TAG item holds the Weighted Modulation Error Ratio (WMER) estimated by the receiver on the FAC cells of the 
current transmission frame and is mandatory for all RX_STAT profiles. The dB-value of this error ratio is presented by 
this TAG item as shown in figure 6.25. If the receiver cannot calculate the WMER because the receiver is not in 
synchronization, an empty TAG item shall be transmitted. 
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TAG 


name 




TAG length 




77\G va/ue 


ASCII rwmf 


1 6 bits or 


Weighted MER 


r 


w 


m 


f 


00i6 


00^6 


00i6 


10,6 


Byte1 


Byte 2 



!-* 4 bytes - 



-4 bytes - 



-2 bytes - 



Figure 6.25: Weighted IVIodulation Error Ratio for FAC cells 
Weighted MER: the format of this single value is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [dB] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 

The TAG value of the TAG item 'rwmf is calculated as follows: For each equalized FAC cell (no SDC cells, no MSC 
cells, no pilot cells), the error vector from the nearest ideal point of the constellation diagram is measured. The squared 
magnitude of this error is found, and a weighted mean of the squared errors is calculated over one frame. In calculating 
that mean, the squared error for each cell is multiplied by the squared magnitude of the estimated channel response for 
that cell. The sum of the weighted values is divided by the sum of the weights to give the weighted mean. The WMER 
is the ratio in [dB] of the mean of the squared magnitudes of the ideal points of the constellation diagram to the 
weighted mean squared error. This gives an estimate of the ratio of the total signal power to total noise power at the 
input of the equalizer. 



WMER = lQlog 



10 



5. 



.fk 



El |2| |2 



with 



Cj. estimated channel responses. 

Sf, optimal point values of the QAM constellation diagram (from hard decision). 

r^ received complex cell values after channel estimation. 

S^ mean energy of used cells. 

The mean energy S^ used in this calculation is an average for all times, i.e. a constant and theoretical value. If a short 
time average is used, additional noise is added to the formula. 



6.4.5.2 



Weighted Modulation Error Ratio for MSC cells (rwmm) 



This TAG item holds the Weighted Modulation Error Ratio (WMER) estimated by the receiver on the MSC cells of the 
current transmission frame and is mandatory for all RX_STAT profiles. The dB-value of this error ratio is presented by 
this TAG item as shown in figure 6.26. If the receiver cannot calculate the WMER because the receiver is not in 
synchronization, an empty TAG item shall be transmitted. 





TAG 


name 




TAG length 




TAG value 


ASCII rwmm 


16 bits or 


Weighted MER 


r 


w 


m 


m 


00i6 


00,6 


00i6 


10,6 


Bytel 


Byte 2 



|-« 4 bytes - 



-4 bytes - 



-2 bytes - 



Figure 6.26: Weighted Modulation Error Ratio for MSC cells 
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For description and calculation of the TAG value see clause 6.4.5.1. Instead of the FAC cells now only the MSC cells 
are used. 



6.4.5.3 



Modulation Error Ratio for actual frame (rmer) 



This TAG item holds the Modulation Error Ratio (MER) for the actual transmission frame and is mandatory for all 
RX_STAT profiles. The dB-value of this error ratio is presented by this TAG item as shown in figure 6.27. If the 
receiver cannot calculate the MER because the receiver is not in synchronization, an empty TAG item shall be 
transmitted. 





TAG 


name 




TAG length 




TAG value 


ASCII rmer 


16 bits or 


Actual MER 


r 


m 


e 


r 


00,6 


00,6 


00,6 


10i6 


Byte1 


Byte 2 



j-* 4 bytes - 



-4 bytes - 



-2 bytes - 



Figure 6.27: Modulation Error Ratio for actual frame 
Actual MER: the format of this single value is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [dB] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 

The calculation of the TAG value for the TAG item 'rmer' is described in TR 101 290 [6]. TR 101 290 [6] notes in 
annex C: "The MER can be regarded as a form of Signal-to-Noise ratio measurement that will give an accurate 
indication of a receiver's ability to demodulate the signal, because it includes, not just Gaussian noise, but all other 
uncorrectable impairments of the received constellation as well". This includes impairments of the signal by the 
transmitter. 

The MER is calculated as follows: For each equalized MSC cell (only MSC cells, no FAC cells, no SDC cells, no pilot 
cells), the error vector from the nearest ideal point of the constellation diagram is measured. The squared magnitude of 
this error is found, and a mean of the squared errors is calculated over one frame. The MER is the ratio in [dB] of the 
mean of the squared magnitudes of the ideal points of the constellation diagram to the mean squared error. This gives an 
estimate of the ratio of the total signal power to total noise power at the input to the equalizer for channels with flat 
frequency response. 



MER = lOlog 



10 



\'k\ 



\^k-rk\ 



with 



6.4.5.4 



optimal point values of the QAM constellation diagram (from hard decision), 
received complex cells values after channel estimation. 

Bit error rate of MSC stream <n> (rbpO, rbp1 , rbp2 and rbp3) 



The Bit Error Rate (BER) of a specific MSC stream is given by the following TAG item as shown in figure 6.28. This 
TAG item is mandatory for RX_STAT profiles A, B, C, and D. If no MSC data is available, an empty TAG item shall 
be transmitted. 
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TAG 


name 




TAG length 




TAG value 


ASCII rbp? 


32 bits or 


Bit Error Rate 


r 


b 


P 


? 


00ie 


00,e 


00i6 


20i6 


No. Errors 


No. Bits 



•■r* 4 bytes 

witin ? = ... 3 



-4 bytes - 



-2 bytes -»-i-*-2 bytes - 



00 



16 



FFFF 



16 



00 



16 



FFFF 



16 



Figure 6.28: Bit error rate of IVISC stream <n> 

The specific MSC stream is referred by use of the TAG name 'rbpC, 'rbpl', 'rbp2' or 'rbp3' appropriate to the stream Id. 

No. errors: number of erroneous bits in the MSC stream identified by stream Id ... 3 of the current multiplex frame as 
16-bit unsigned integer value. 

No. bits: total number of received bits in the MSC stream identified by stream Id ... 3 of the current multiplex frame 
as 16-bit unsigned integer value. 

Please see clause 7 for details when to calculate the BER of an MSC stream. 



6.4.5.5 



Delay window (rdel) 



The following TAG item provides information of the delay window for a given percentage of signal energy as shown in 
figure 6.29. If the receiver is not in synchronization an empty TAG item shall be transmitted. This TAG item is 
mandatory for all RX_STAT profiles. 



TAG name 



TAG length 



TAG value 



ASCII rdel 


24n bits or 
with n= 1 ... 10 


Delay Window 


r 


d 


e 


1 


90 % value 




99 % value 


-* 4 bytes - 


■^ I -. A l^w4-«^ 


n 


Tbytc 






■" 1- uyioo "■ 







Percentage 



Window Length 



-1 byte- 



-2 bytes - 



Byte 1 



Byte 2 



Figure 6.29: Delay window 

The delay window for x % of signal energy shall be calculated and given as defined in ITU-R Recommendation 

P. 1407 [7]. A multiple of three bytes represents the specific percentage of signal energy within the delay window and 

the length of the delay window as follows: 

Percentage: the percentage [%] of signal energy within the delay window as 8-bit unsigned integer value. 

Window length: the format of this value is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [ms] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 
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The first three -byte group represents the mandatory 90 % energy window. An arbitrary number of optional three-byte 
groups (up to a maximum of nine additional groups) can follow the mandatory three-byte group. Suggested values are 
for 95 % and 99 % of the signal energy, which results in nine bytes of TAG value. The maximal TAG length is 30 bytes 
for ten three-byte groups. 

The calculation of the energy percentages is done on the sum of the squared absolute values of the estimated impulse 
responses of all symbols in a transmission frame. Estimation implies filtering and interpolation between successive 
symbols. The steps of calculation are as follows: 

1) estimate the complex cell gains for the current symbol for all carriers, where gain reference pilots are 
available, using interpolation or filtering mechanisms; 

2) calculate the impulse response by using the estimated complex cell gains; 

3) calculate the squared absolute values of the complex impulse response values; 

4) sum up the values from step 3 for each carrier in all symbols of a transmission frame - the result is an averaged 
impulse response; 

5) calculate the total energy Pjot^i by summing up the averaged impulse response; 

6) step from each border of the averaged impulse response inwards as long as the desired threshold P^^ (the given 
percentage of the total energy Pjotal) i^ ^'^^ reached or exceeded: P^j^ = Pfotai ' (1 ~ ^ ^ 100) ^ 2; 

7) calculate the delay value from the distance of the two detected positions. 



6.4.5.6 



Doppler estimation (rdop) 



With the TAG item 'rdop' a value of Doppler estimation on the received signal is transported as shown in figure 6.30. If 
the receiver is not in synchronization an empty TAG item shall be transmitted. This TAG item is mandatory for all 
RX_STAT profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII rdop 


16 bits or 


Doppler Estimation 


r 


d 





P 


00i6 


00^6 


00i6 


10i6 


Byte1 


Byte 2 



I-* 4 bytes - 



-4 bytes - 



-2 bytes - 



Figure 6.30: Doppler estimation 
Doppler estimation: the format of this value is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [ms] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE 1: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 

The Doppler estimation measures the vector change, from one symbol to the next, in the individual paths making up the 
impulse response. The estimate is an average rate of rotation calculated as though the vector change were normal to the 
path in each case. Hence a path whose phase is constant but whose amplitude is changing will also give a fairly 
representative contribution. Small angle approximations are applied, i.e. the estimate assumes that the Doppler is slow 
compared to the symbol rate. Every frame an average of all symbols within that frame is sent. 

NOTE 2: A factor of two is included so that the estimate is of the two-sided range of Doppler shifts. A channel with 
two equal paths, whose Doppler shifts are H-1 Hz and -1 Hz respectively, will give a reading of 2 Hz. 

For channels with Doppler spread, the estimate will reflect the instantaneous rate at which the channel is changing, 
possibly giving an explanation for audio dropouts. The Doppler spread itself is a long-term statistical property of the 
channel and we make no claim to estimate it. 
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The Doppler estimation is calculated as follows: 

1) start with estimates of the complex impulse response from two successive symbols (symbols n-1 and n); 

2) take the difference between corresponding samples in the two estimates; 

3) find the square root of the sum of the squares of magnitudes of these differences - this is the 'RMS difference'; 

4) find the square root of the sum of the squares of magnitudes of the samples of the complex impulse response 
estimate for the more recent symbol (symbol n) - this is the 'RMS magnitude'; 

5) divide the RMS difference by the RMS magnitude, divide the result by tt and multiply by the symbol rate for 
the current mode. 

The calculation of the TAG value for the TAG item 'rdop' is expressed by the following formula: 



rdop ■■ 



^|/z„(/)-Vl(')|' 



;zr. 



Y,M 



with 



h^ (i) is the ;-th sample of the complex impulse response estimate for symbol n. 

NOTE 3: It is easy to understand the rationale behind the method by considering the above procedure applied to the 
impulse response. However, the same answer could be obtained by applying the same procedure to the 
estimated frequency response. This is because the Fourier Transformation is linear, hence the difference 
between transformations is equal to the transformation of the difference. Additional Parseval says, the 
sum of squares in the frequency domain is k^ ■ (sum of squares in time domain). The result above is based 
on the ratio of two sums of squares, so the gain factor k of the Fourier Transformation cancels out. 



6.4.5.7 



Power Spectral Density (rpsd) 



The last TAG item of the measurements section is one which holds the values of the Power Spectral Density (PSD) of 
the received signal as shown in figure 6.3 1 . Only in case that no input signal is available, an empty TAG item shall be 
transmitted. Because of data rate reasons this TAG item is mandatory for RX_STAT profiles A and D only. 





TAG 


name 


TAG length 




TAG value 




ASCII rpsd 


Snbits or 
here: 680 or 111 2 bits 


Power Spectral Density 


r 


P 


s 


d 


Value 1 


Value 2 




Value n 






byte 


















1 




Integer Part 


Decimal Place 




-« — 7 bits 




1 h 


it .^i 













Figure 6.31 : Power Spectral Density 

Each single value of the Power Spectral Density (PSD) is of the following format: 
Power Spectral Density value n: one 8-bit byte per value with: 

• Integer part: 7 bits (most significant bits of the byte) for the absolute integer value of the calculated negative 
floating point PSD value. 

• Decimal place: 1 bit (LSb) for the rounded decimal place in steps of 0.5 dB of the calculated floating point 
PSD value. 
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Therefore the covered PSD signal range is -127,0 dB (FEjg in terms of the TAG value) to 0,0 dB (OOjg). 

If a receiver is not capable of evaluating the PSD for each of the described frequencies (see below), the value for all not 
calculated or invalid frequencies shall be set to FF^g (-127,5 dB) as special case of the TAG value. If some values are 

valid but calculated to be lower than -127,0 dB, they have to be limited to the minimum of -127,0 dB (FE^g). 

The values are generated by performing a one-dimensional FFT on the IQ input signal with a frequency spacing of 
187,5 Hz. The FFT uses Banning windowing. This gives a resolution bandwidth of 281,25 Hz. The sampling is done 
using 50 % overlap. This results in 150 FFTs per transmission frame. 

For generation of one 'rpsd' TAG item for one transmission frame, all the frequency energy output values of the FFTs 
are averaged. The FFT energy values are upscaled by a factor of 4 because of windowing and downscaled (divided) by 
the number of windows per frame which is 150. 



PSDif) = lOlogio 



150 



El |2 

\FFTvalue(f)\ 



EXAMPLE 1 ; By the use of an IQ input signal (sampling frequency 48 kHz) this results in a complex 256-point 
FFT running 150 times for one frame (19 200 complex samples per frame with 50 % overlap 
equals 38 400 complex samples; 38 400 samples / 256 FFT taps = 150). 

The number of values put in the TAG value of this TAG item is restricted to the values out of a frequency range seen 
from the DC -carrier of -8/H-8 kHz for the half and full bandwidth DRM transmission modes (4,5 kHz, 5 kHz, 9 kHz, and 
10 kHz nominal bandwidth) and -8/H-18 kHz for the double bandwidth DRM transmission modes (18 and 20 kHz 
nominal bandwidth). 

EXAMPLE 2; By the use of an IQ input signal (sampling frequency 48 kHz) this results in a number of 85 values 
(-42 FFT-lines, DC, H-42 FFT-Unes or -7 875 kHz to +7 875 kHz in steps of 187,5 Hz) respectively 
139 values (-42 FFT-hnes, DC, H-96 FFT-Unes or -7 875 kHz to H- 18 000 kHz in steps of 
187,5 Hz). The DC-carrier is value number 43 in both cases. 

6.5 TAG items for RX_CTRL 

The TAG items within the following clauses are defined for RX_CTRL communication. 
TAG packets comprising RX_CTRL TAG items with commands for the receiving unit: 

• can be sent to the receiver at any time; 

• do not include any counter like the RX_STAT TAG packets; and 

• shall be processed by the receiver before sending out a new RX_STAT TAG packet. If the receiver is currently 
sending out a RX_STAT TAG packet at the moment of arrival of the RX_CTRL TAG packet, the commands 
will not affect the actual RX_STAT TAG packet but first the next one. 

If the TAG value of a TAG item has a fixed size then the size is given at the point TAG length. Some of the TAG items 
have variable data length due to a variable size of the TAG value. This is indicated by the expression "variable". The 
length is then given in the TAG value description. For some TAG items the TAG value may sometimes not be 
available. Such TAG items are marked by "or 0" at the point TAG length. 

The communication is uni-directional. 

The receiver is listener only. The reception of a RX_CTRL TAG packet is not acknowledged by the receiver, but can be 
controlled implicit by looking at the changes of the RX_STAT data that do appear or even not. 



6.5.1 TAG items for receiver settings 



The following TAG items are to set the demodulation type and frequency for the transmission which is intended to be 
received and which service the receiver should listen to. 
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6.5.1.1 



Activate receiver (cact) 



To set the receiving equipment in active state or standby for reception the following TAG item is used as shown in 
figure 6.32. This TAG item is mandatory for all RX_CTRL profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII cact 


8 bits 


Activate Receiver 


c 


a 


c 


t 


00i6 


00,, 


00i6 


08i6 


ASCII '0' or '1' 



i-* 4 bytes - 



-4 bytes - 



-1 byte- 



Figure 6.32: Activate receiver 
Activate receiver: this ASCII character gives the desired active status for the reception equipment as follows: 



ASCII' 0' 
ASCII' 1' 

6.5.1.2 



deactivate 
activate 



Set reception frequency (cfre) 



To set the reception frequency for the current transmission the TAG item 'cfre' is used as shown in figure 6.33. This 
most important RX_CTRL TAG item is mandatory for all RX_CTRL profiles. 





TAG 


name 




TAG length 




TAG value 


ASCII cfre 


32 bits 


Reception Frequency 


c 


f 


r 


e 


00,6 


00,6 


00,6 


20i6 


00,6...FFFFFFFF,6 



'!^ 4 bytes - 



-4 bytes - 



-4 bytes - 



Figure 6.33: Set reception frequency 
Reception frequency: 32-bit unsigned integer value in [Hz]. 
The receiver should set the reception frequency of the HF front-end as close to this frequency value as possible. 



6.5.1.3 



Set receiver demodulation type (cdmo) 



This TAG item signals the demodulation type to be used to the receiver in ASCII notation as shown in figure 6.34 and 
is mandatory for all RX_CTRL profiles. See also TAG item 'rdmo' at clause 6.4.2.1. 



TAG name 



TAG length 



TAG value 



ASCII cdmo 


32 bits 


Receiver Demodulation Type 


c 


d 


m 





00,6 


00,6 


00,6 


20i6 


drm_ or am 



'r* 4 bytes - 



-4 bytes - 



-4 bytes - 



Figure 6.34: Set receiver demodulation type 

The information on the demodulation type for the receiver to be used is given as four ASCII characters: 



drm_ 
am 



DRM demodulation 
AM demodulation 
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6.5.1.4 



Set IF filter bandwidth (cbws and cbwg) 



The IF filter bandwidth the receiver front-end should use can be set with one of the following both TAG items as shown 
in figure 6.35. These TAG items are not mandatory because it can not be assumed that the receiving RSCI protocol 
parser unit is able to change the IF filter bandwidth of the HF front-end. 





TAG 


name 




TAG length 




TAG value 


ASCII cbw? 


1 6 bits 


IF Filter Bandwidth 


c 


b 


w 


? 


00i6 


00,, 


00i6 


10i6 


Byte1 


Byte 2 



j-* 4 bytes - 



-4 bytes - 



-2 bytes - 



with ? = 's' or 'g' 

Figure 6.35: Set IF filter bandwidth 
IF filter bandwidth: the format is (Bytel + Byte2 / 256) = (Bytel.Byte2) in [kHz] with: 

• Bytel is an 8-bit signed integer value; and 

• Byte2 is an 8-bit unsigned integer value. 

NOTE: This is the same as to put Bytel and Byte2 into a signed 16-bit integer value (Bytel is the higher part) and 
to divide this value by 256. 

The TAG items 'cbws' and 'cbwg' both specify the desired IF filter bandwidth but differ in the way the value is 
interpreted: 

• TAG item 'cbws': From its available range of filter bandwidths, the receiver should choose the highest 
possible bandwidth which is smaller or equal than the requested bandwidth. In case that the lowest available 
bandwidth is greater than the requested value, the receiver should choose this value. 

• TAG item 'cbwg': From its available range of filter bandwidths, the receiver should choose the lowest 
possible bandwidth which is greater or equal than the requested bandwidth. In case that the highest available 
bandwidth is smaller than the requested value, the receiver should choose this value. 



6.5.1.5 



Select service (cser) 



The service identifier (short Id) of the service to be selected at the GUI is given by the following TAG item as shown in 
figure 6.36. This selection is important because the audio status (see clauses 6.4.3.3, 6.4.3.7 and 6.4.3.8) refers always 
to the selected service (see clause 6.4.3.5). Therefore this TAG item is mandatory for all RX_CTRL profiles. 



TAG name 



TAG length 



TAG value 



ASCII cser 


8 bits 


Select Service 


c 


s 


e 


r 


00i6 


00i6 


00,, 


08,, 


Oio-3io 



'r* 4 bytes - 



-4 bytes - 



-1 byte- 



Figure 6.36: Select service 
Select service: 8-bit signed integer value specifying the short Id (0 to 3) of the service to be selected. 

6.5.2 TAG items for signal recording 

The following TAG items are to switch on and off signal recording options of the receiver unit remotely. 
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6.5.2.1 



Start/stop recording (crec) 



Using the TAG item 'crec' as shown in figure 6.37 start/stop commands can be sent to the receiver to switch remotely on 
or off recordings of the received signal or of a specific RX_STAT profile. 



TAG name 



TAG length 



TAG value 



ASCII crec 


32 bits 


Start/Stop Recording 


c 


r 


e 


c 


00,e 


00i6 


00i6 


20i6 


iq_1 , iq_0, st?1 or st?0 



'r^ 4 bytes - 



-4 bytes - 



-4 bytes - 



witin ? = 'a', 'b', 'c', 'd' or 'q' 

Figure 6.37: Start or Stop recording 

The information on the recording type to be started or stopped is given as four ASCII characters: 



iq_l 
iq_0 

stal 
staO 
stbl 
stbO 
stcl 
stcO 
stdl 
stdO 
stql 
stqO 



start recording of the input signal as IQ-file 
stop recording of the input signal as IQ-file 



start recording 
stop recording 
start recording 
stop recording 
start recording 
stop recording 
start recording 
stop recording 
start recording 
stop recording 



ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX_ 
ofRX 



STAT 
STAT 
STAT 
STAT 
STAT 
STAT 
STAT 
STAT 
STAT 
STAT 



profile A output into a file 

profile A output 

profile B output into a file 

profile B output 

profile C output into a file 

profile C output 

profile D output into a file 

profile D output 

profile Q output into a file 

profile Q output 



The name of the recorded files shall be generated automatically matching the following format string: 

XXXXXXXXXXXXXXXX_YYYY-MM-DD_HH-MM-SS_FFFFFFFF.EXT 

XXXX...XXXX ASCII text as transmitted in TAG item 'rinf (see clause 6.4.3.1) 
YYYY-MM-DD year, month and day in UTC time at the moment the recording starts 
HH-MM-SS hours, minutes and second in UTC time at the moment the recording starts 
FFFFFFFF reception frequency in [Hz] 

EXT file name extension as defined below 

For IQ-file recording the file name extension indicates the sample rate: 

.iql2 stands for a sample rate of 12 kHz 

. iq2 4 stands for a sample rate of 24 kHz 

. iq4 8 stands for a sample rate of 48 kHz 

The IQ-file comprises only the plain IQ-samples without any header information. The format of the IQ-samples is a 
16-bit signed integer value for the I- or Q-sample, whereby the I-sample comes first with little endian byte order and 
LSb first. 

For the status output recording the file name extension indicates the recorded RX_STAT profile: 



, rsA 
, rsB 
,rsC 
, rsD 
. rsQ 



stands for a recording of RX_STAT profile A 
stands for a recording of RX_STAT profile B 
stands for a recording of RX_STAT profile C 
stands for a recording of RX_STAT profile D 
stands for a recording of RX_STAT profile Q 



Recording into file shall be done via the file layer described in TS 102 821 [2]. No PFT layer is used. 
The receiver should generate a new file as soon as the reception frequency is changed. 
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If the receiver has not implemented the RX_STAT profile desired for recording, it should record the most close profile. 
The most close profile is the next smaller one providing most of the information of the desired profile or better the next 
bigger one comprising completely the information of the desired profile. In this context the ascending order of the 
RX_STAT profiles is B — «• C — > A — > D. Profile Q can be placed before profile B or between profiles B and C 
depending on the necessary TAG items. 

6.6 Revision history 

Table 6.3 contains the history of the TAG item changes of the RSCI protocol for each new revision. 

Table 6.3: Revision history 



Major revision 


lUlinor revision 


Date 


Changes from previous to new revision 


OOOS^e 


0000^5 


2004-03-01 


Initial public release 



Changes to the protocol which will allow existing decoders to still function will be represented by an increment of the 
minor version number only. Any new features added by the change will obviously not need to be supported by older 
modulators. Existing TAG items will not be altered except for the definition of bits previously declared as 'rfu'. New 
TAG items may be added. 

Changes to the protocol which will render previous implementations unable to correctly process the new format will be 
represented by an increment of the major version number. Older implementations should not attempt to decode such 
TAG packets. Changes may include modification to or removal of existing TAG item definitions. 



7 Test and measurement 

A test and measurement transmission: 

• as a stand-alone data service is signalled by the application identifier (see FAC service parameters in 

ES 201 980 [1], clause 6.3.4) with a value of 31 jg "skip indicator" (former "test and measurement" as stated in 
TS 101 968 [4], clause 4.2: the skip indicator is to allow for engineering test transmissions to be ignored by 
standard receivers). Additionally the type of test and measurement transmission is indicated in SDC 
application information data entity - type 5 as stated below. 

• as programme associated data (the data stream is associated with an audio stream/service) is signalled only in 
SDC application information data entity - type 5 as stated below. 

One type of test transmission is the transmission of a Pseudo Random Bit Sequence (PRBS). This provides the 
possibility to measure Bit Error Rates (BER) by comparing the received sequence with the locally generated error-free 
one. 

The PRBS can be used in two ways: 

• Synchronous PRBS: is resetted to start state (all memory taps in delay line are set to I2) at the start of each 
super frame. 

• Asynchronous PRBS: is a free running PRBS, which can start with any start value (except O2 for all memory 
taps in delay line). 

The SDC application information data entity - type 5 (see ES 201 980 [1], clause 6.4.3.6 and TS 101 968 [4], 
clause 4.3) of a test and measurement transmission containing a PRBS data stream will be of the following format: 



Short Id 


2 bits 




Stream Id 


2 bits 




Packet Mode Indicator 


Ibit 


O16 


rfa 


3 bits 


0,fi 
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• Enhancement Flag 1 bit Oj^ 

• Application Domain 3 bits Ojg 

• Application Id 16 bits 8001 jg 

• Application Data 40 bits (see below) 
Short Id: this field indicates the short Id for the service concerned. 

Stream Id: this field indicates the stream Id of the stream, which carries the PRBS data concerned. 

Packet mode indicator: this field indicates with value O^g that the service is carried in synchronous stream mode. 

rfa: these three bits are reserved for future additions and shall be set to zero until they are defined. 
Enhancement flag: this field indicates with value Ojg that no enhancement data is available in another channel. 

Application domain: this field indicates with value O^g that the source of the data application is the application domain 
'DRM' (see TS 101 968 [4], clause 4.3.1). 

Application Id: this field indicates with value 8001 jg that the data application is a 'DRM specified proprietary data 
apphcation' (see TS 101 968 [4], clause 4.3.2.1). 

The application data field is filled as required by the corresponding application specification and in the actual case for a 
test and measurement transmission containing a PRBS data stream as follows: 

• Synchronous Flag 1 bit ^jgorl^g 

• rfa 7 bits OOjg 

• Generator Polynomial 32 bits 00000000 ^ g ... FFFFFFFFjg 

Synchronous flag: this field indicates whether the indicated stream holds a synchronous (O^g) or asynchronous (1 jg) 
PRBS. 

rfa: these seven bits are reserved for future additions and shall be set to zero until they are defined. 

Generator polynomial: this bit field indicates the generator polynomial - length of the shift register (tap delay line) 
with its feedbacks - to generate the PRBS. 

The generator polynomial GJ^x) = x^ + ... + x^ + 1 is signalled by the bits number a down to z set to I2 for the feedbacks 

x^ ... x^, the remaining bits are set to O2. In this context the LSb of the fourth byte is bit number one tantamount to 

feedback x^ (if present). The first feedback at 1 = x*' is not signalled because it is present for all PRBS. The most 
significant 1-bit (bit number a at feedback x^) gives the needed length of the shift register (tap delay line) up to the 
maximum register length of 32. 

For test and measurement transmissions the following sequence is used: This PRBS is generated by a shift register (tap 
delay line) of length 23 connected as shown in figure 7. 1 resulting in the generator polynomial G23(x) = x^^ + x'^ + 1 . 
The register contents are initially all set to I2 (for a synchronous PRBS at the start of each super frame, for an 
asynchronous PRBS only at the first time) such that the sequence begins: OOOOOOOOg OOOOOOOOg OOlllllOg 
OOOOOOOO2 OOOOIIII2 IIIIIIOO2 OOOOOOII2 IIIOOOOO2 IIIIIOOO2 IIII2 - Successive groups of 
eight bits are assembled into bytes, with the first bit becoming the MSb of the byte. 
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PRBS 



^23 



^f^^^^^^^^^^^^^f^^^^^^^f^^^^^f^^^^ 



EXAMPLE: 



Figure 7.1 : Shift register for PRBS G23(x) generation 

In case of a synchronous PRBS with generator polynomial G23(x) = x^^ + x'^ + 1 the application 
data field is filled with the following values: 



Synchronous Flag 1 bit 

rfa 7 bits 

Generator Polynomial 32 bits 



0l6 
00i6 

42OOOO16 : 



1000010 00000000 OOOOOOOOo 



In general every PRBS (up to a register length of 32) can be used because the generator polynomial is announced to the 
receiver in SDC application information data entity - type 5. So the receiver is able to adapt to the actual used sequence. 

As soon as one data service or the programme associated data of an audio service is identified to contain PRBS data, a 
RX_STAT profile A, B, C or D compliant receiver has to start to evaluate the BER of the referred data stream and 
output the BER on the according 'rbp?' TAG item. If this not possible for any user-defined PRBS, so at least for the 
special case of test and measurement transmissions using PRBS G23(x) the BER evaluation shall be done. 



£75/ 



44 



ETSI TS 102 349 V1.1.1 (2005-01) 



History 



Document history 


VI. 1.1 


January 2005 


Publication 



























£75/ 



